ROS2 通信机制综合实践与课程总结

关联：索引

• 数据传输：至少 1 个 Topic 在多节点间稳定传输（能 topic echo --once 得到结构化数据）。

• 设备控制：至少 1 个 Service 能完成指令下发与返回（能返回 ok/error_code/message）。

• 长时任务交互：至少 1 个 Action 能反馈进度并正确结束（成功/取消/超时至少覆盖其一）。

• 证据链：至少包含 rqt_graph 节点关系图 + 终端日志关键行（含 task_id/request_id 与 error_code）。

• 接口契约不得临时改字段；发现不一致先对齐接口再改节点。

• 话题/服务/动作命名统一使用绝对名称（以 /sorting/... 为例），避免隐式 namespace 混淆。

• 每个小组只跑 1 条最小闭环链路，先通再扩。

• 角色分工（建议）：集成负责人（统一启动与联调）、证据链记录员（截图与记录）、排障执行员（按命令验证与修复）。

• 启动口径：所有终端统一 source install/setup.bash；统一使用绝对名称 /sorting/...；统一记录启动顺序与每个终端执行命令。

2. 运行顺序建议（示例口径）

1）先起数据源（Topic publisher）
2）再起控制入口（Service server）
3）最后起长时任务（Action server）
4）再起客户端/调度节点（如有）

3. 命令级联调清单（必须跑）

# 用法说明：
# - <topic_name>/<service_name>/<action_name>：替换成你们项目里的实际名称（建议用绝对名 /xxx/yyy）
# - <pkg>/srv/<Srv>、<pkg>/action/<Action>：替换成你们实际接口类型（可用 `ros2 service list -t` / `ros2 action list -t` 查看）

# 1）观察系统现状（多节点整合的第一现场）
# 目的：确认“节点/通道有没有起来”，避免一上来就 debug 代码
ros2 node list
ros2 topic list -t
ros2 service list -t
ros2 action list -t

# 2）就绪性检查（避免“服务端没起来就去调用”）
# 现象：调用 service/action 报错或超时
# 结论：wait 能返回，说明服务端至少已注册成功
ros2 service wait <service_name>

# 3）Action 侧信息（是否存在、类型是什么）
# 目的：确认 action 名称与类型；同时能看到 action 服务器信息
ros2 action info <action_name>

# 4）Topic：从系统角度验证“有数据在流动”
# - hz：看频率是否稳定（系统整合时，频率异常往往意味着某个回调阻塞/定时器不准）
# - echo --once：抓一条消息，确认字段结构是否正确
ros2 topic hz <topic_name>
ros2 topic echo <topic_name> --once

# 5）Service：沿用上一讲你们已经通过的验收命令（把 <...> 按本组接口替换）
# - 建议先用 `ros2 service list -t` 确认类型，再 call
# - "{...}" 中字段名必须严格按 srv 定义填写，否则会提示字段不存在或类型不匹配
ros2 service call <service_name> <pkg>/srv/<Srv> "{...}"

# 6）Action：沿用上一讲你们已经通过的验收命令（把 <...> 按本组接口替换）
# - --feedback：实时看反馈（没有反馈通常是服务端没 publish 或根本没收到 goal）
# - "{...}" 字段名必须严格按 action 定义填写
ros2 action send_goal <action_name> <pkg>/action/<Action> "{...}" --feedback

1. 拓扑证据（rqt_graph）

• 要求：图中能看到你们本组关键节点与至少 3 条连线（Topic/Service/Action 各至少一个交互点）。
• 抽查点：链路是否连通；是否出现“孤岛节点”（只启动不通信）。

2. 数据证据（rqt_plot 或 topic hz）

# 目的：快速判断 Topic 发布频率是否符合预期（系统整合期很关键）
ros2 topic hz <topic_name>

如果当前 Topic 不便于直接绘制数值字段，优先绘制 Action 的进度反馈（progress 典型为 0.0~1.0）：

# 用法说明：
# - <action_name> 替换成动作名（建议绝对名）
# - Action 的 feedback topic 通常类似：<action_name>/_action/feedback
# - feedback 内部字段路径取决于你们自定义的 Feedback 消息结构（progress 仅为常见示例）
# - 若不确定路径：先用 `ros2 topic list -t | grep <action_name>` 找到 feedback 话题，再 `ros2 topic echo <feedback_topic> --once` 查看字段层级
rqt_plot <action_name>/_action/feedback/feedback/progress

• 能解释：为什么你们这条链路必须用 Topic + Service + Action，而不是只用一种机制

1. 综合排障口径（重点抓“系统因素”）

# 用法说明：
# - 先判断“有没有”，再判断“对不对/能不能用”
# - 多节点问题优先从命名、类型、就绪性、图谱连通性排起

# 1）系统里有没有这些节点（最常见：节点其实没启动或启动后立刻退出）
ros2 node list

# 2）通道名与类型是否对齐（含 -t 看类型）
# - list -t 可以看到每个 topic/service/action 的类型
# - 若类型不一致：要么接口包没对齐，要么命名用了另一个同名通道
ros2 topic list -t
ros2 service list -t
ros2 action list -t

# 3）有没有数据/响应/反馈（把“存在”与“可用”区分开）
# - service wait：服务端是否 ready
# - action info：action 服务端是否存在
# - echo/hz：topic 是否真正有数据在流动（很多时候能 list 到，但实际收不到）
ros2 service wait <service_name>
ros2 action info <action_name>
ros2 topic echo <topic_name> --once
ros2 topic hz <topic_name>

# 4）图谱是否连通（找“孤岛”与错误连接）
# - 孤岛节点：只启动但没连上任何 topic/service/action
# - 错误连接：通道名相近但不一致（多 1 个前缀、少 1 段 namespace）
rqt_graph

2. 常用调试命令速查（系统整合期更常用）

# 节点侧（定位“谁在发/谁在收”）
# - node info：查看某节点订阅/发布了哪些 topic，提供/调用了哪些 service/action
ros2 node list
ros2 node info <node_name>

# Topic 侧（定位“看得见但收不到/频率不稳/QoS 不匹配”）
# - topic info -v：能看到 publisher/subscriber 数量与 QoS 概要（排查 QoS 不匹配很有用）
# - bw：带宽估算（频率正常但带宽异常，可能消息太大或某端拥塞）
ros2 topic list -t
ros2 topic type <topic_name>
ros2 topic info <topic_name> -v
ros2 topic echo <topic_name> --once
ros2 topic hz <topic_name>
ros2 topic bw <topic_name>

# Service 侧（定位“是否可用/类型是否匹配/谁提供服务”）
# - service find：按类型反查有哪些服务名（当你只知道接口类型、不知道服务名时）
ros2 service list -t
ros2 service type <service_name>
ros2 service find <pkg>/srv/<Srv>
ros2 service wait <service_name>
ros2 service call <service_name> <pkg>/srv/<Srv> "{...}"

# Action 侧（定位“是否存在/反馈是否在发/是否可取消/结果状态是否正确”）
# - cancel：取消当前目标（要求 action 服务器正确实现取消语义）
ros2 action list -t
ros2 action info <action_name>
ros2 action send_goal <action_name> <pkg>/action/<Action> "{...}" --feedback
ros2 action cancel <action_name>

# 接口契约（定位“字段名/类型是否一致”）
# - show：输出 msg/srv/action 的字段定义（字段名写错是最常见的调用失败原因之一）
ros2 interface show <pkg>/msg/<Msg>
ros2 interface show <pkg>/srv/<Srv>
ros2 interface show <pkg>/action/<Action>

# 排查“列表/图谱不刷新”（发现信息陈旧时）
# - daemon 是 ROS2 CLI 的后台发现服务；偶尔会缓存陈旧信息
ros2 daemon stop
ros2 daemon start

# 参数侧（定位“配置不一致导致行为不同”）
# - 常见：不同终端启动参数不同，导致 QoS/频率/话题名不同
ros2 param list <node_name>
ros2 param get <node_name> <param_name>

• 故障 A（依赖未就绪）：先调用 Service/Action，再启动服务端，观察超时/失败现象，调整启动顺序并回归。

• 故障 B（节点异常退出）：停止/退出一个关键节点，观察链路断裂，定位“断点在哪个交互段”，恢复并回归。

• 故障 C（数据频率不稳）：让 Topic 发布频率偏离预期，用 ros2 topic hz 与日志定位阻塞点，修复并回归。

• 故障 D（命名空间混淆）：使用相对名称或不同 namespace 启动导致通道对不上，用 list -t 与 rqt_graph 定位，统一口径并回归。

• 接口契约：字段名、类型、语义是否完全对齐（不得“猜字段”）。

• 命名与路径：topic/service/action 名称是否统一且可被 list -t 验证。

• 异常边界：Service 参数校验是否给出可定位的 error_code/message；Action 是否区分取消/超时/失败。

• 日志可定位：关键路径是否打印 request_id/task_id 与 error_code，能否支持“按日志复盘”。

2. 与上一讲提示词的差异点（本讲补充证据）

• “证据”额外补充：启动顺序与每个终端的启动命令、rqt_graph 截图、list -t 的输出（含类型）。
• “修复”额外补充：若涉及 namespace/相对名称，需说明最终统一口径（绝对名或统一 namespace）。

1. 一页纸复盘框架（小组统一产出）

• 通信选型：本组链路中每个交互点为什么用 Topic/Service/Action（用一句话写清）。
• 接口契约：每个 msg/srv/action 的关键字段语义（只写“必须用到的字段”，不抄接口全文）。
• 节点职责：每个节点的输入/输出/异常边界（各 3 行以内）。
• 排障复盘：本次遇到的 1 个综合问题与证据链（现象→证据→修复→回归）。

2. 通信机制知识点回顾（课程总结版）

• Topic：高频数据流与状态广播；重点关注 QoS（可靠性/历史/深度）、频率稳定性、数据可观测性（hz/echo/plot）。
• Service：短时请求-响应控制；重点关注参数校验、超时与错误码语义、幂等性口径（重复请求怎么处理）。
• Action：长时任务交互；重点关注反馈频率与语义、取消/超时/失败区分、最终状态表达与上层策略联动。

| --- | --- | --- |
| 高频/连续数据，允许丢帧或需 QoS 控制 | Topic | topic hz 稳定；echo --once 字段完整 |
| 必须立即得到结果/错误原因（短任务） | Service | service wait 就绪；call 有明确 ok/error_code/message |
| 任务耗时较长，需要进度与取消 | Action | send_goal --feedback 有反馈；可取消/超时；final_state 语义清楚 |

3. 重点难点总结（本讲收束）

• 多节点联动：一处命名/QoS/启动顺序的偏差会被系统放大，必须用 list -t + rqt_graph 缩小范围。

• 通信选型：不要为了“统一”硬塞一种机制，按“频率/是否需要响应/是否长时可取消”选。

• 你们修复的 1 个综合问题（现象→证据→修复→回归）

• 你们下一步的通信模块开发计划（节点清单 + 测试矩阵 + 风险点）

• 把“最小闭环链路”扩展为“多链路系统”：检测/调度/规划/执行/状态上报与告警的接口与节点拆分。

• 强化工程化交付：统一启动方式（脚本或 launch）、参数化配置、日志规范与最小回归测试清单。

• 深化联调与运维：QoS 与性能调优、异常注入与回归、监控与排障手册沉淀（可复现的证据链模板）。

作业：综合大作业（课后提交）

1）提交分拣系统通信机制综合实战的代码包（含所有自定义接口、节点代码），附代码目录结构截图。

2）提交多节点通信运行成功的截图（至少包含：rqt_graph 节点关系图、终端日志、rqt_plot 数据曲线）。

3）提交至少 2 次 AI 协同开发的交互记录（分别用于生成通信节点代码、排查通信故障），并撰写 200 字左右说明，阐述 AI 生成内容的审计、优化过程及心得体会。

4）整理模块学习笔记，总结通信机制原理、接口设计、AI 协同开发的重点难点，结合小组产业项目，梳理通信模块后续开发计划（200 字左右）。